Size Change: +1.22 kB (0%)

Total Size: 1.42 MB

_{compressed-size-action}

Flaky tests detected in 2ec62ae.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5502420340
📝 Reported issues:

• [Flaky Test] should not allow blocks to be inserted in inner blocks #44341 in specs/editor/plugins/cpt-locking.test.js

The pagination is currently done client side as mentioned in the PR description above. @youknowriad Do you have any concerns about this approach? I can try to put up another draft PR implementing the server side solution if needed.

Seems to work well - nice work! A couple of things with initial testing:

Do we want the load more button to be full width?

With a couple of hundred patterns loaded the Delete pattern flow is pretty slow and janky - not sure how we get around this as pulling one item out causes a full list rerender 🤔

@SaxonF I know this isn't properly designed yet, but just wondering if we need more distinction between left nav and the pattern list, it looks like an indistinct sea of black at the moment:

This worked well for me. I am noticing some sluggishness, especially when the previews of the patterns are loading. When I try to do something else when this is happens it seems as though all interactions are blocked.

For example, search for a pattern and let that load. Then clear the search and try immediately clicking on one of the "All/Synced/Standard" filters. You'll notice interaction is blocked until the previews of all the patterns are loaded.

I think it's fine to start with client side pagination but I do remember some very old feedback that some folks had a very high number of reusable blocks (synced patterns). So I think ultimately, it's better to do server side pagination.

There's also the question of the design, I know there are some concerns about the infinite scrolling but "load more" button is really not a great UX experience for most users. cc @jasmussen @mtias @SaxonF I think it's probably an opportunity to find a solution that works great in terms of UX once and for all, but I do expect the behavior to find its place in other pages... but also addresses the a11y concerns. One option could be to make this an a11y preference.

I think it's probably an opportunity to find a solution that works great in terms of UX once and for all, but I do expect the behavior to find its place in other pages... but also addresses the a11y concerns. One option could be to make this an a11y preference.

If we can work out an elegant a11y solution my preference mid term would be infinite scroll + search + filters (e.g.by sync status, author, date etc) + sorting (name, modified date, created date etc). That combination would offer a nice mix to cover both browse and search tasks. This should be done on the server.

In the short term though, we need something for 6.3 to minimise client-side performance issues. I doubt we'll get infinite scroll in a nice place before then, so we either enforce a limit of ~100 patterns on a page and rely on search to find older patterns, or we include a load more button.

Is the main purpose of the PR the client side performance? Did we try / are we using useAsyncList here? Like in the inserter...

Is the main purpose of the PR the client side performance? Did we try / are we using useAsyncList here? Like in the inserter...

The main bottleneck is rendering all the <BlockPreview>s on the same page. I'm not sure how useAsyncList will help with that? It could be a potential optimization for initial rendering though.

The main bottleneck is rendering all the s on the same page. I'm not sure how useAsyncList will help with that? It could be a potential optimization for initial rendering though.

We've found that the initial rendering is the problem that causes freezing. After initial rendering there's not much "re-rendering" happening (there's some but not impactful), so we've built useAsyncList to be able to lazily render the patterns as the browser allows (requestIdleCallback). I think it would be good to use the same solution used before for the exact same problem.

We've found that the initial rendering is the problem that causes freezing. After initial rendering there's not much "re-rendering" happening (there's some but not impactful), so we've built useAsyncList to be able to lazily render the patterns as the browser allows (requestIdleCallback).

Thanks for the additional info! I was not aware of this finding. However, isn't this solution basically the same as infinite loading? Only that it automatically loads the next items without user interactions. I'm not familiar with the accessibility concerns of the infinite loading approach, but if it's not relevant here we can definitely give it a try!

Another gotcha I failed to mention is that this screen allows editing and deleting items on the same page. If we pass in per_page: -1 to fetch all the patterns in one go and do client-side filtering, regardless we use the infinite loading approach, we'll run into the following problem:

1. User deletes (updates) an item.
2. Cache invalidates, refetch the list with the same query (per_page: 1).
3. It takes a long time to fetch the whole list because the REST API can only handle 100 items at a time. The middleware sequentially fetches each page and then concatenates them together on the client.
4. The UI finally updates.

I'm not familiar with the core-data internals to know how to fix this. But a general solution is to leverage optimistic update and do the re-fetching behind the scenes. Another potential solution is to disable invalidating the cache of the whole list since we only allow individual updates at the time. Maybe there's a quick solution already implemented somewhere that I'm not aware of though!

Thanks @youknowriad, I switched it to use useAsyncList which improves the performance even when displaying the limited list of results. We will merge this in as is and then circle back and sort the pagination.

Manually cherry-picked into https://github.com/WordPress/gutenberg/tree/update/beta-4-second-round.

@kevin940726, I noticed (while testing #53666) that the usePatterns hook returns a new patterns reference on each mapSelect call.

If the Patterns API doesn't support filtering, we should perform it outside the useSelect hook.